The following answers have been successfully submitted to 'Call for Review: Decentralized Identifiers (DIDs) v1.0 is a W3C Proposed Recommendation' (Advisory Committee) for Mozilla Foundation by Tantek Çelik. Regarding the "Decentralized Identifiers (DIDs) v1.0" specification, the reviewer suggests the document not be published as a Recommendation [Formal Objection] (your details below). Additional comments about the specification: Summary: * No practical interoperability. * Encourages divergence rather than convergence. * Centralized methods allowed, in contradiction to WG & spec goals & name. * Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y). No practical interoperability. As Microsoft & Google expressed, the DID “Core” spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ “methods”, none of which themselves have interoperable implementations. We agree with the analogy to URLs & schemes, as Google noted: “precedent set by the development of URLs, in which RFC 1738 standardized 10 schemes at the same time as it standardized URLs in general”. The Web has similar experience with the img tag & image formats, and the video tag & video formats. In each of those cases, there were multiple interoperable formats before the tags themselves were standardized. In addition, we agree with the comments made by Microsoft to “recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.” Encourages divergence rather than convergence. The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods. Note this is in contrast with prior examples given (URL schemes, image & video formats). Thus, whether intended or not, the DID specification (and perhaps its inherent architecture) is designed in such a way that encourages divergence of implementations, rather than convergence & interoperability. The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability. In particular: * Centralized methods allowed, in contradiction to WG & spec goals & name. As Google noted, some methods in the registry such as did:ccp use a single server, and thus any interop with such a method would bias toward centralization, and likely be literally centralized rather than decentralized. Centralization might be at an architectural level, or – at a minimum – a service level, even if multiple “implementations” claimed to support it. * Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y). Also as noted by Google, the registry contains methods which rely upon proof-of-work which is wasteful. “Successful” proof-of-work systems waste a staggering amount of electricity world-wide (e.g. Bitcoin consumes more energy than most countries <https://www.forbes.com/sites/niallmccarthy/2021/05/05/bitcoin-devours-more-electricity-than-many-countries-infographic/>) demonstrating that the more such methods are adopted, the more their energy requirements grow, without any discernible upper bound, which is grossly irresponsible given the global environmental crisis (recent IPCC report <https://www.bbc.co.uk/news/science-environment-58130705>). Lawrence Berkeley National Laboratory suggested “the registry should include a requirement to provide system- and processor-independent assessment of the energy requirements of any methods being registered.” We don’t think this goes far enough. We (W3C) can no longer take a wait-and-see or neutral position on technologies with egregious energy use. We must instead firmly oppose such proof-of-work technologies including to the best of our ability blocking them from being incorporated or enabled (even optionally) by any specifications we develop. If anything we should pursue the opposite: develop specifications that supersede existing specifications, but with much less power consumption. We believe this is consistent with the TAG Ethical Web Sustainability principle (<https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable>). For these reasons we believe the DID specification may not be fixable (MUST NOT become a Recommendation). We suggest returning the specification to Working Draft status. The reviewer's organization: - does not expect to produce or use products or content addressed by this specification Answers to this questionnaire can be set and changed at https://www.w3.org/2002/09/wbs/33280/did-core-pr/ until 2021-08-31. Regards, The Automatic WBS MailerReceived on Wednesday, 1 September 2021 02:30:03 UTC
This archive was generated by hypermail 2.4.0 : Wednesday, 1 September 2021 02:30:04 UTC